Uml overview modified

1,297 views

Published on

UML Oops Design Patterns

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,297
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
50
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Uml overview modified

  1. 1. UML DESIGNING 1
  2. 2. UML OverviewIntroductionModeling is an activity that has been carried out over the years in software development.When writing applications by using the simplest languages to the most powerful andcomplex languages, you still need to model. Modeling can be as straightforward asdrawing a flowchart listing the steps carried out by an application. Why do we usemodeling? Defining a model makes it easier to break up a complex application or a hugesystem into simple, discrete pieces that can be individually studied. We can focus moreeasily on the smaller parts of a system and then understand the "big picture." Hence, thereasons behind modeling can be summed up in two words: • Readability • ReusabilityReadability brings clarity—ease of understanding. Understanding a system is the firststep in either building or enhancing a system. This involves knowing what a system ismade up of, how it behaves, and so forth. Modeling a system ensures that it becomesreadable and, most importantly, easy to document. Depicting a system to make itreadable involves capturing the structure of a system and the behavior of the system.Reusability is the byproduct of making a system readable. After a system has beenmodeled to make it easy to understand, we tend to identify similarities or redundancy, bethey in terms of functionality, features, or structure.Even though there are many techniques and tools for modeling, in this article series, wewill be concerning ourselves with modeling object-oriented systems and applicationsusing the Unified Modeling Language. The Unified Modeling Language, or UML, as it ispopularly known by its TLA (three-letter acronym!), is the language that can be used tomodel systems and make them readable. This essentially means that UML provides theability to capture the characteristics of a system by using notations. UML provides a widearray of simple, easy to understand notations for documenting systems based on theobject-oriented design principles. These notations are called the nine diagrams of UML.So the question arises, Why is UML the preferred option that should be used formodeling? Well, the answer lies in one word: "standardization!" Different languages havebeen used for depicting systems using object-oriented methodology. The prominentamong these were the Rumbaugh methodology, the Booch methodology, and theJacobson methodology. The problem was that, although each methodology had itsadvantages, they were essentially disparate. Hence, if you had to work on differentprojects that used any of these methodologies, you had to be well versed with each ofthese methodologies. A very tall order indeed! The Unified Modeling Language is justthat. It "unifies" the design principles of each of these methodologies into a single,standard, language that can be easily applied across the board for all object-orientedsystems. But, unlike the different methodologies that tended more to the design anddetailed design of systems, UML spans the realm of requirements, analysis, and designand, uniquely, implementation as well. The beauty of UML lies in the fact that any of thenine diagrams of UML can be used on an incremental basis as the need arises. Forexample, if you need to model requirements for a given system, you can use the usecase diagrams only without using the other diagrams in UML. Considering all thesereasons, it is no wonder that UML is considered "the" language of choice.UML does not have any dependencies with respect to any technologies or languages.This implies that you can use UML to model applications and systems based on either of 2
  3. 3. the current hot technologies; for example, J2EE and .NET. Every effort has been madeto keep UML as a clear and concise modeling language without being tied down to anytechnologies.This series aims to cover the basics of UML, including each of the nine diagrams ofUML. In addition, you will get to learn about the tools available that support UML. At theend of each article, we will incrementally build each of the nine UML diagrams for a casestudy system in the coming weeks. We will wrap our study of UML by expanding into twodifferent areas—Rational Unified Process and Design Patterns.UML DiagramsThe underlying premise of UML is that no one diagram can capture the differentelements of a system in its entirety. Hence, UML is made up of nine diagrams that canbe used to model a system at different points of time in the software life cycle of asystem. The nine 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 objects 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 3
  4. 4. 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 somehowgroup together these diagrams to enable us to further understand how to use them.UML Diagram Classification—Static, Dynamic, and ImplementationA software system can be said to have two distinct characteristics: a structural, "static"part and a behavioral, "dynamic" part. In addition to these two characteristics, anadditional characteristic that a software system possesses is related to implementation.Before we categorize UML diagrams into each of these three characteristics, let us takea quick look at exactly what these characteristics are. • Static: The static characteristic of a system is essentially the structural aspect of the system. The static characteristics define what parts the system is made up of. • Dynamic: The behavioral features of a system; for example, the ways a system behaves in response to certain events or actions are the dynamic characteristics of a system. • Implementation: The implementation characteristic of a system is an entirely new feature that describes the different elements required for deploying a system.The UML diagrams that fall under each of these categories are: • Static o Use case diagram o Class diagram • Dynamic o Object diagram o State diagram o Activity diagram o Sequence diagram o Collaboration diagram 4
  5. 5. Implementation o Component diagram o Deployment diagramFinally, let us take a look at the 4+1 view of UML diagrams.4+1 View of UML DiagramsConsidering that the UML diagrams can be used in different stages in the life cycle of asystem, let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers adifferent perspective to classify and apply UML diagrams. The 4+1 view is essentiallyhow a system can be viewed from a software life cycle perspective. Each of these viewsrepresents how a system can be modeled. This will enable us to understand whereexactly the UML diagrams fit in and their applicability.These different views are: • Design View: The design view of a system is the structural view of the system. This gives an idea of what a given system is made up of. Class diagrams and object diagrams form the design view of the system. • Process View: The dynamic behavior of a system can be seen using the process view. The different diagrams such as the state diagram, activity diagram, sequence diagram, and collaboration diagram are used in this view. • Component View: Next, you have the component view that shows the grouped modules of a given system modeled using the component diagram. • Deployment View: The deployment diagram of UML is used to identify the deployment modules for a given system. This is the deployment view of the • Use case View: Finally, we have the use case view. Use case diagrams of UML are used to view a system from this perspective as a set of discrete activities or transactions.SummaryIn the first article of this series, we took a quick background at what UML is and where itfits in the overall software life cycle. Each of the nine diagrams that make up UML will becovered step by step in the coming weeks. Before we start with our study of each ofthese nine diagrams, we will take a look at what UML tools are available in the market inthe next article. 5
  6. 6. UML ToolsBy Mandar Chitnis, Pravin Tiwari, & Lakshmi AnanthamurthyIn the previous article, we gained an overview of what the Unified Modeling Languagestands for and what are the nine diagrams that make up UML. Because UML isessentially a set of diagrams, you can simply draw them by hand on a piece of paper.But, drawing UML diagrams on a piece of paper is certainly not a best practice to designsystems. Software applications simplify the task of drawing diagrams of softwaredesigns. In addition, because the design is in an electronic format, archiving the designfor future use, collaborating on the design becomes much easier. Also, routine tasks canbe automated by using a UML tool. Hence, using a UML tool is by far the most preferredway for designing software applications.Features in UML ToolsThis takes us to an important question—what exactly should we look for in a UML tool?Because the primary use of a UML tool is to enable you to draw diagrams, first andforemost, we need to see what types of UML diagrams the tool supports. But, is drawingUML diagrams all that you would expect from a UML tool? For example, wouldnt it begreat if the class diagrams that you draw in the tool can somehow be used to generatethe source code for actual Java classes or C++ classes?Let us take a look at another scenario. Suppose you were given a large set of sourcecode files with lots and lots of classes. Wouldnt it be a nightmare wading through thecode trying to figure out how all the classes are interconnected? This is where UML toolsstep in to make things a lot easier by providing support for such features. Now, letsdefine these features in technical terms: • UML diagram support: The UML tool should support all the nine diagrams that make up UML. You should look for a tool that supports drawing use cases, designing the static view diagrams such as class diagrams and object diagrams, defining the dynamic view diagrams such as sequence, activity, state, and collaboration diagrams and the component and deployment diagrams that form the implementation view of the system. • Forward engineering: A UML tool should not have its use limited to just a pictorial depiction of diagrams. Because the structure of the system defined by the diagram is translated by a developer into actual source code (classes), the UML tool should bridge this step by generating the source code of the classes with the methods stubbed out. Developers can take up this stub code and fill in with the actual code. This characteristic of automating the generation of source code is called forward engineering. Forward engineering support by a UML tool is normally for a specific language or a set of languages. If you are a Java developer, verify that the UML tool that you want to use has forward engineering support for Java. Similarly, if you are a C++ developer, the UML tool should provide you forward engineering support for C++. • Reverse engineering: Reverse engineering is exactly the opposite of forward engineering. In reverse engineering, the UML tool loads all the files of the application/system, identifies dependencies between the various classes, and essentially reconstructs the entire application structure along with all the relationships between the classes. Reverse engineering is a feature normally provided by sophisticated and high-end UML tools. 6
  7. 7. • Round-trip engineering: Another useful feature apart from forward and reverse engineering is round-trip engineering. Forward and reverse engineering are essentially one-off activities that take input and generate the required output. Round-trip engineering extends these features.• An important rule in software design is that no design remains unchanged. This is as true for small systems as it is for large systems. During development, the design structure defined in the UML model does undergo changes to incorporate physical differences in implementation that may not have been envisaged during design. It becomes very difficult to keep the design of the system updated with the changes in the source code. The round-trip engineering feature enables the UML tool to synchronize the model with the changes in the application code.• Documentation: Documentation is an integral aspect of a UML tool. Software designing, by nature, is an abstract process. Apart from a few syntax and semantic ground rules, there are no other rules. The thought process of a software architect who designs applications using UML can be lost if the reasons behind certain design decisions are not captured and well documented. This becomes painfully clear when large systems are maintained and no one has a clue to why a subsystem was designed in a certain way. Hence, a UML tool must necessarily provide some way for the designer to document design decisions in the diagrams by using simple things such as annotations or comments. In addition to this, the UML tool should support the generation of reports/listings of the different design elements of the diagram. Apart from the above features, you should also identify a few features that would definitely be useful to have in the UML tool.• Version control: A very important feature that we want to have in the UML tool is either an integrated version control mechanism or connectivity to a standard version control system. Configuration management is an integral part in the building of software systems. Considering that the design of a system is a very important artefact of the software lifecycle, maintaining versions and baselines of the system design is a desirable feature to have in UML tools. In the absence of direct support for version control, it is the responsibility of the designer to maintain versions of the design.• Collaborative modeling environment: Enterprise systems are huge and their designs are quite complex. While designing complex systems, there may be different teams involved and may carry out design work on different subsystems in parallel. This collaborative design effort needs to be properly synchronized by the UML tool. The UML tool should provide support for a collaborative modeling environment with capability to compare different versions designs for differences or even merge different versions of a design. Collaborative modeling is always a nice feature to have in UML tools.• Integration with popular Integrated Development Environments (IDE): With the increasing use of iterative methodologies for building software systems, it becomes very difficult to keep the design of the system in sync with the developed code. Hence, it would be useful if the UML tool provides integration with popular IDEs. This feature would enable the UML tool to be updated with the changes in the source code made in the IDE. 7
  8. 8. • Test script generation: The system or subsystem designed in a UML tool may represent a set of functional aspects as well. Hence, it would be really useful if, in addition to generating stub code, the tool also generates test scripts that can be used for testing how the generated class functions. • Model View Controller (MVC) modeling: Enterprise application architectures have increasingly begun to standardize and are based on the Model View Controller architecture. Hence, if you design n-tier, Web-enabled enterprise applications, you should look for a UML tool that supports designing applications based on the MVC architecture. Support for MVC modeling makes it easier to organize and clearly distinguish the design elements along the lines of the MVC layers. This will help in the long run in improving the readability of the model. Template-driven modelingRe-usability is the key to improving productivity. An application design may consist ofseveral classes with relationships defined. Quite a few times, while designingapplications, you encounter the same design problems or scenarios and end up definingthe same design again and again. By using a modeling tool, you can define certaincomponents or even subsystems that might potentially be reusable in the future. Forexample, design elements of an application used to define access to the database using,say, a ConnectionPool class are potentially reusable. You might need to define a similardatabase connection pool in another application as well. Hence, it would benefit us in thelong run if we design the ConnectionPool class separately. We then can include theConnectionPool design in any future subsystems and avoid the need of reinventing thewheel.Such reusable designs or models are termed as templates and the entire modelingprocess involving the identification and use of templates is called template-drivenmodeling. The benefits of template-driven modeling are apparent in the savings in designtime. You can consider model templates to be very similar to reusable code libraries usedin application development.Popular UML ToolsWe will list here a few of the "movers and shakers" of vendors of UML tools. Please notethat this list is by no means exhaustive and is not meant to provide any ranking for anyUML tool. • Rational Rose: No discussion of UML tools is complete without the mention of the Rational Rose modeling tool from Rational Software Corporation. Rational Rose (the Rose stands for "Rational Object-oriented Software Engineering") is a visual modeling tool for UML. It comes in different versions suited to different requirements. Rational Rose provides support for all the standard features that we discussed in the previous section such as UML diagram support, forward and reverse engineering support, and documentation and round-trip engineering support. Apart from this, Rational Rose also provides support for version control, IDE integration, design pattern modeling, test script generation, and collaborative modeling environment. In addition, Rational Rose also supports the designing of data models within the same environment. An interesting feature of Rational Rose is the ability to publish the UML diagrams as a set of Web pages and images. This enables you to share and distribute your application design where the Rational Rose tool is not installed. 8
  9. 9. • Together Control Center: Together Control Center (formerly from Togethersoft) from Borland is an entire suite of visual modeling tools for UML. Together Control Center supports UML diagrams, MVC modeling, forward and reverse engineering, and round-trip engineering, as well as integration with IDEs such as IBM WebSphere Studio. It supports comprehensive documentation and a powerful collaborative modeling environment. An added feature of Together Control Center is the pattern repository. The pattern repository (similar to the template-driven modeling concept discussed above) makes frequently used diagrams and design patterns readily available for reuse in modeling. Together Control Center supports the Rational Unified Process as well as the eXtreme Programming methodologies. • Poseidon: Poseidon from Gentleware has its roots in the ArgoUML open source project. The ArgoUML modeling tool evolved as an open source effort and is a useful, full-featured UML tool freely available under the Open Publication License. Gentleware has taken ArgoUML a step further and turned it into a good modeling tool. Poseidon comes in different flavors suited to different requirements. Poseidon supports forward and reverse engineering and documentation generation by using special-purpose plug-ins. Gentleware has not forgotten its open source moorings and offers the Poseidon for UML Community Edition 1.5 free for individual software developers.Integration of UML Tools with Integrated Development Environments (IDEs)One interesting feature in UML tools that we discussed in the previous section wasround-trip engineering. For round-trip engineering to be useful, we need to have the UMLtool to be used in conjunction with an IDE. This integration of a UML tool with the IDE willhelp you to really benefit from round-trip engineering. Any changes in the applicationcode that you make in the IDE are immediately reflected in the model in the UML tooland vice versa. For our discussion, we will be considering IDEs for the Java language.Quite a few of the UML tools on the market can be integrated with the popular IDEs suchas IBMs WebSphere Studio, Borlands JBuilder, WebGains Visual Café, or Suns Forte.For instance, Rational Rose (Java edition) provides integration with all of these popularIDEs. Together Control Center has a special version that integrates with IBMsWebSphere Studio.The downside of UML tool integration is that the integration solution is proprietary to theUML tool vendor. Hence, you might not always find a UML tool providing integration withpopular IDEs in the market. But all this is changing. (See box for details on the Eclipseproject.) 9
  10. 10. EclipseEclipse is an open source effort that has tool integration as the long-term goal. Theinteresting aspect of Eclipse is that the effort is supported by major tool vendors. Eclipseaims to define across-the-board integration standards that will enable vendors of differenttools to seamlessly work together and provide a cohesive and single developmentenvironment. The beauty of Eclipse is that the integration between tools is not aproprietary solution. In laymans terms this means that, for example, you can buy an off-the-shelf UML tool and integrate it into your development environment without having toworry that you might be stuck with a particular vendor or group of vendors. Eclipse isdefinitely an area to watch out for in the near future! (www.eclipse.org)Case StudyWe will apply the UML concepts that we will be discussing through the coming weeksand design an entire real world application. Each session in the coming weeks will berounded off with designing the case study application incrementally using each of theUML diagrams.For our case study, we will be the architects assigned the task of constructing the designelements for a system that can be used to manage coursees/classes for an organizationthat specializes in providing training. Let us name the system that we will be designingas the Courseware Management System. The organization offers a variety of courses ina variety of areas such as learning management techniques and understanding differentsoftware languages and technologies. Each course is made up of a set of topics. Tutorsin the organization are assigned courses to teach according to the area that theyspecialize in and their availability. The organization publishes and maintains a calendarof the different courses and the assigned tutors every year. There is a group of courseadministrators in the organization who manage the courses including course content,assign courses to tutors, and define the course schedule. The training organization aimsto use the Courseware Management System to get a better control and visibility to themanagement of courses as also to streamline the process of generating and managingthe schedule of the different courses.Now that we have our problem statement defined, we can proceed to the next step—analyzing and elaborating on the requirements and then designing the CoursewareManagement System in the coming weeks.SummaryUML tools will form the basis of our activities in the coming weeks. Each of the UMLdiagrams that we will cover will be built using any of the available UML tools in themarket. Todays discussion helped us understand what features we should look for whenselecting a UML tool. Apart from the "must-have" features, we also checked out a "wishlist" of features that a UML tool could have. The classroom courseware case studyapplication that we discussed will be designed using when we cover each of the UMLdiagrams in the coming weeks. 10
  11. 11. Creating Use Case DiagramsOver the previous two articles, we took a brief look at the nine UML diagrams and whatkind of tools you can use to model UML diagrams. Now that we have our basics clear,we will start our study of these nine UML diagrams. Today we will cover the Use casediagram. We will learn the basics of use case diagrams and try our hand at drawing ause case diagram. In addition, we will see what a use case specification is. Finally, wewill attempt to apply what we have learned of use cases and model the use casediagrams for our case study application—the Courseware Management System.BasicsBefore we start off todays article, let us revisit the definition of use a case diagram, asdescribed in the first article. 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.The above statement pretty much sums up what a use case diagram is primarily madeup of—actors and use cases.A use case diagram captures the functional aspects of a system. More specifically, itcaptures the business processes carried out in the system. As you discuss thefunctionality and processes of the system, you discover significant characteristics of thesystem that you model in the use case diagram. Due to the simplicity of use casediagrams, and more importantly, because they are shorn of all technical jargon, use casediagrams are a great storyboard tool for user meetings. Use case diagrams have anotherimportant use. Use case diagrams define the requirements of the system being modeledand hence are used to write test scripts for the modeled system.So who should normally be involved in the creation of use cases? Normally, domainexperts and business analysts should be involved in writing use cases for a givensystem. Use cases are created when the requirements of a system need to be captured.Because, at this point no design or development activities are involved, technical expertsshould not be a part of the team responsible for creating use cases. Their expertisecomes in use later in the software lifecycle.Elements of a Use Case DiagramA use case diagram is quite simple in nature and depicts two types of elements: onerepresenting the business roles and the other representing the business processes. Letus take a closer look at use at what elements constitute a use case diagram. • Actors: An actor portrays any entity (or entities) that performs certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. For example, for modeling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. But it is up to you to consider what actors make an impact on the functionality that you want to model. If an entity does not affect a certain piece of functionality that you are modeling, it makes no sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary, as shown in Figure 3.1. 11
  12. 12. Figure 3.1: an actor in a use case diagram To identify an actor, search in the problem statement for business terms that portray roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system.• Use case: A use case in a use case diagram is a visual representation of a distinct business functionality in a system. The key term here is "distinct business functionality." To choose a business process as a likely candidate for modeling as a use case, you need to ensure that the business process is discrete in nature. As the first step in identifying use cases, you should list the discrete business functions in your problem statement. Each of these business functions can be classified as a potential use case. Remember that identifying use cases is a discovery rather than a creation. As business functionality becomes clearer, the underlying use cases become more easily evident. A use case is shown as an ellipse in a use case diagram (see Figure 3.2). Figure 3.2: use cases in a use case diagram Figure 3.2 shows two uses cases: "Make appointment" and "Perform medical tests" in the use case diagram of a clinic system. As another example, consider that a business process such as "manage patient records" can in turn have sub- processes like "manage patients personal information" and "manage patients medical information." Discovering such implicit use cases is possible only with a thorough understanding of all the business processes of the system through discussions with potential users of the system and relevant domain knowledge.• System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system. 12
  13. 13. Figure 3.3: a use case diagram depicting the system boundary of a clinic application Figure 3.3 shows the system boundary of the clinic application. The use cases of this system are enclosed in a rectangle. Note that the actors in the system are outside the system boundary. The system boundary is potentially the entire system as defined in the problem statement. But this is not always the case. For large and complex systems, each of the modules may be the system boundary. For example, for an ERP system for an organization, each of the modules such as personnel, payroll, accounting, and so forth, can form the system boundary for use cases specific to each of these business functions. The entire system can span all of these modules depicting the overall system boundary.Relationships in Use CasesUse cases share different kinds of relationships. A relationship between two use cases isbasically a dependency between the two use cases. Defining a relationship between twouse cases is the decision of the modeler of the use case diagram. This reuse of anexisting use case using different types of relationships reduces the overall effort requiredin defining use cases in a system. A similar reuse established using relationships, will beapparent in the other UML diagrams as well. Use case relationships can be one of thefollowing: • Include: When a use case is depicted as using the functionality of another use case in a diagram, this relationship between the use cases is named as an include relationship. Literally speaking, in an include relationship, a use case includes the functionality described in the another use case as a part of its business process flow. An include relationship is depicted with a directed arrow having a dotted shaft. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<<include>>" identifies the relationship as an include relationship. Figure 3.4: an example of an include relationship 13
  14. 14. For example, in Figure 3.4, you can see that the functionality defined by the "Validate patient records" use case is contained within the "Make appointment" use case. Hence, whenever the "Make appointment" use case executes, the business steps defined in the "Validate patient records" use case are also executed. • Extend: In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<<extend>>" identifies the relationship as an extend relationship, as shown in Figure 3.5. Figure 3.5: an example of an extend relationship Figure 3.5 shows an example of an extend relationship between the "Perform medical tests" (parent) and "Perform Pathological Tests" (child) use cases. The "Perform Pathological Tests" use case enhances the functionality of the "Perform medical tests" use case. Essentially, the "Perform Pathological Tests" use case is a specialized version of the generic "Perform medical tests" use case. • Generalizations: A generalization relationship is also a parent-child relationship between use cases. The child use case in the generalization relationship has the underlying business process meaning, but is an enhancement of the parent use case. In a use case diagram, generalization is shown as a directed arrow with a triangle arrowhead (see Figure 3.6). The child use case is connected at the base of the arrow. The tip of the arrow is connected to the parent use case. Figure 3.6: an example of a generalization relationshipOn the face of it, both generalizations and extends appear to be more or less similar. Butthere is a subtle difference between a generalization relationship and an extendrelationship. When you establish a generalization relationship between use cases, thisimplies that the parent use case can be replaced by the child use case without breaking 14
  15. 15. the business flow. On the other hand, an extend relationship between use cases impliesthat the child use case enhances the functionality of the parent use case into aspecialized functionality. The parent use case in an extend relationship cannot bereplaced by the child use case.Let us see if we understand things better with an example. From the diagram of ageneralization relationship (refer to Figure 3.6), you can see that "Store patient records(paper file)" (parent) use case is depicted as a generalized version of the "Store patientrecords (computerized file)" (child) use case. Defining a generalization relationshipbetween the two implies that you can replace any occurrence of the "Store patientrecords (paper file)" use case in the business flow of your system with the "Store patientrecords (computerized file)" use case without impacting any business flow. This wouldmean that in future you might choose to store patient records in a computerized fileinstead of as paper documents without impacting other business actions.Now, if we had defined this as an extend relationship between the two use cases, thiswould imply that the "Store patient records (computerized file)" use case is a specializedversion of the "Store patient records (paper file)" use case. Hence, you would not be ableto seamlessly replace the occurrence of the "Store patient records (paper file)" use casewith the "Store patient records (computerized file)" use case.Creating the Use Case DiagramFor drawing use case diagrams, you need to use any tool that supports use casediagrams. We will be using the Poseidon Community Edition tool for drawing the usecase diagram, as shown in Figure 3.7. You can use any tool that you are comfortablewith. A use case modeling tool provides a palette of options to draw actors and usecases and to define relationships between the use cases. . Figure 3.7: a screen shot of the Poseidon toolTake a look at the screen shot of the Poseidon tool. You can see the different options itprovides to draw the use case diagram elements. In addition to drawing the use casediagram elements such as actors and use cases, you also can define relationshipsbetween use cases. Apart from this, the tool also provides capability to document thedifferent elements that we draw. This documentation can be viewed as a consolidatedreport for future reference. 15
  16. 16. An additional feature that you can check in your modeling tool is support for generatingtest scripts from the use case diagram. A comprehensive use case diagram provides agood foundation for basing test cases for the system that you model.Writing a Use Case SpecificationA use case diagram, as we have seen, is a visual depiction of the different scenarios ofinteraction between an actor and a use case. The usefulness of use case diagrams ismore as a tool of communication between the requirements capture team and the usergroup. The next step after finalizing of use case diagrams is to document the businessfunctionality into clear-cut and detailed use case specifications. Because use cases areused as an input to the other project phases such as design, development, and testing,we need to ensure that the visual depiction of the business requirements is translatedinto clear and well-defined requirements in the form of use case specifications. Elaborateuse case specifications are used as an input for design and development and for writingtest cases (unit, system, and regression tests, as the case may be).A use case specification document should enable us to easily document the businessflow. Information that you document in a use case specification includes what actors areinvolved, the steps that the use case performs, business rules, and so forth. A use casespecification document should cover the following areas: • Actors: List the actors that interact and participate in this use case. • Pre-conditions: Pre-conditions that need to be satisfied for the use case to perform. • Post-conditions: Define the different states in which you expect the system to be in, after the use case executes. • Basic Flow: List the basic events that will occur when this use case is executed. Include all the primary activities that the use case will perform. Be fairly descriptive when defining the actions performed by the actor and the response of the use case to those actions. This description of actions and responses are your functional requirements. These will form the basis for writing the test case scenarios for the system. • Alternative flows: Any subsidiary events that can occur in the use case should be listed separately. Each such event should be completed in itself to be listed as an alternative flow. A use case can have as many alternative flows as required. But remember, if there are too many alternative flows, you need to revisit your use case design to make it simpler and, if required, break the use case into smaller discrete units. • Special Requirements: Business rules for the basic and alternative flows should be listed as special requirements in the use case narration. These business rules will also be used for writing test cases. Both success and failure scenarios should be described here. • Use case relationships: For complex systems, it is recommended that you document the relationships between use cases. If this use case extends from other use cases or includes the functionality of other use cases, these 16
  17. 17. relationships should be listed here. Listing the relationships between use cases also provides a mechanism for traceability.Dos and DontsUse cases should not be used to capture all the details of a system. The granularity towhich you define use cases in a diagram should be enough to keep the use casediagram uncluttered and readable, yet, be complete without missing significant aspectsof the required functionality. You will encounter such decision points of the level ofgranularity that you need to define when you build any of the UML diagrams.An important rule that gets forgotten during use creation is the creeping in of designissues. Use cases are meant to capture "what" the system is, not "how" the system willbe designed or built. Use cases should be free of any design characteristics. If you endup defining design characteristics in a use case, you need to go back to the drawingboard and start again.Case study—Courseware Management SystemUse case modeling, as we have learnt today, involves analyzing the problem statementto determine the business processes of the system. We will now design the use casemodel for the Courseware Management System case study.Let us analyze the problem statement to identify the potential actors and use cases ofthe system. First, let us list the potential actors. A quick look at the problem statementshows up the following terms and entities specific to the system: • Courses and Topics that make up a course • Tutors who teach courses • Course administrators who mange the assignment of the courses to tutors • Calendar or Course Schedule is generated as a result of the • Students who refer to the Course schedule or Calendar to decide which courses they wish to take up for studyIdentifying Actors of the Courseware Management SystemOut of the preceding list, one thing is clear. There are certain terms and entities in the listthat identify that they perform certain roles or business processes. We will discuss whatthese business processes are after we complete our analysis for identifying actors. Fornow, we focus on identifying the actors in the system. From the preceding list, we cansee that there are some entities that perform an action and some that form the target forthe action. The entities that perform action will be the actors for the CoursewareManagement System. In the above list, the actors that we can identify are: • Tutors • Course administrators • StudentsBut, because students are not the potential active participants for this system, we willdrop them from the list of actors. Similarly, tutors are not active participants from oursystems perspective, and hence, we will exclude tutors from our list if roles. Yet, we willstill record them in our use case model since we do not wish to lose this businessinformation. Our final list of primary actors has now come down to only one: • Course administrators 17
  18. 18. Identifying Use Cases of the Courseware Management SystemNext, let us identify the potential business processes in the Courseware ManagementSystem. The primary business flows in the system are: • Manage courses • Manage course assignmentsAs we analyze the problem statement further, we can determine some discreteprocesses within these primary business flows. To manage courses, the actor needs tohave the ability to view existing courses, manage the course information for a course,such as duration and so forth, and also manage the addition or removal of topics for acourse. So, within the "Manage courses" use case, we can identify the following subprocesses: • View courses • Manage topics for a course • Manage course informationAnd similarly, the "Manage course assignment" use case can be refined into smallerdiscrete processes such as viewing the course calendar, viewing tutors, managing thetutor information of tutors working for the organization, and of course, assigning coursesto tutors. Now, the use cases that we have identified within the "Manage courseassignment" use case are: • View course calendar • View tutors • Manage tutor information • Assign courses to tutorsOur final list of use cases for the courseware management system will now be: • View courses • Manage topics for a course • Manage course information • View course calendar • View tutors • Manage tutor information • Assign courses to tutorsIf you were analyzing a sentence in English, the subject in the sentence can be identifiedas a potential actor and the verb part of the sentence can be a potential use case.Remember, this may or may not apply to the problem at hand, but is a good starting pointfor use case modeling. 18
  19. 19. Use Case Diagram Figure 3.8: the use case diagram for the Courseware Management SystemWe have completed identifying potential use cases and actors. Take a look at the usecase diagram for the Courseware Management System in Figure 3.7. The use casediagram of the Courseware Management System includes all the actors and use casesthat we identified during our analysis of the problem statement.SummaryUse case diagrams were the starting point of our journey in exploring each of the UMLdiagrams. Business functionality can be quickly represented in a simple and lucid fashionby using use case diagrams. Once the groundwork for depicting use cases is completed,the next step, as we learnt today, is writing detailed use case scenarios that will be usedas the base functional requirements for the system. Our exercise in defining the usecase diagram for the Courseware Management System case study was useful andenabled us to get a hands-on experience in applying what we learnt today.The UML Class Diagram: Part 1In the last article, we saw what use cases were, and how to identify and create usecases. Taking the series ahead, in this article, we will see what class diagrams are, whatthe elements of a class diagram are, what each of these elements signify, and how toidentify them. In our next article, a sequel to this one, we will see how to create classdiagrams for our case study—Courseware Management System. By the end of thesecond article, you will be able to define classes for a system and read and create classdiagrams. 19
  20. 20. BasicsSo, what is a class diagram? Imagine you were given a task of drawing a family tree.The steps you would take would be: • Identify the main members of the family • Determine how they are related to each other • Identify the characteristics of each family member • Find relations among family members • Decide the inheritance of personal traits and charactersA class diagram is similar to a family tree. A class diagram consists of a group of classesand interfaces reflecting important entities of the business domain of the system beingmodeled, and the relationships between these classes and interfaces. The classes andinterfaces in the diagram represent the members of a family tree and the relationshipsbetween the classes are analogous to relationships between members in a family tree.Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, likea set of parent classes (the grand patriarch or matriarch of the family, as the case maybe) and related child classes under the parent classes.Similarly, a software application is comprised of classes and a diagram depicting therelationship between each of these classes would be the class diagram.By definition, a class diagram is a diagram showing a collection of classes andinterfaces, along with the collaborations and relationships among classes and interfaces.A class diagram is a pictorial representation of the detailed system design. Designexperts who understand the rules of modeling and designing systems design thesystems class diagrams. A thing to remember is that a class diagram is a static view of asystem. The structure of a system is represented using class diagrams. Class diagramsare referenced time and again by the developers while implementing the system.Now you now know what a class diagram is. But, how does a class diagram relate to theuse case diagrams that you read about in the earlier article? When you designed the usecases, you must have realized that the use cases talk about "what are the requirements"of a system. The aim of designing classes is to convert this "what" to a "how" for eachrequirement. Each use case is further analyzed and broken up into atomic componentsthat form the basis for the classes that need to be designed.However, besides use cases, the artifacts of a project, such as stakeholder requests,(signed off) requirement documents, functional specifications, and a glossary of terms forthe project serve as other important inputs to the discovery of classes.We will now see what the components of a class diagram are, and how to create a classdiagram.Elements of a Class DiagramA class diagram is composed primarily of the following elements that represent thesystems business entities: • Class: A class represents an entity of a given system that provides an encapsulated implementation of certain functionality of a given entity. These are exposed by the class to other classes as methods. Apart from business functionality, a class also has properties that reflect unique features of a class. 20
  21. 21. The properties of a class are called attributes. Simply put, individual members ofa family of our family tree example are analogous to classes in a class diagram.As an example, let us take a class named Student. A Student class representsstudent entities in a system. The Student class encapsulates student informationsuch as student id #, student name, and so forth. Student id, student name, andso on are the attributes of the Student class. The Student class also exposesfunctionality to other classes by using methods such as getStudentName(),getStudentId(), and the like. Let us take a look at how a class is represented in aclass diagram.A class is represented by a rectangle. The following diagram shows a typicalclass in a class diagram: Figure 4.1.1—the structure of a classIf you are familiar with object-oriented concepts, you will be aware of the conceptof access modifiers. You can apply access modifiers such as public access,protected access, and private access applied to methods and attributes of a class—even to a class as well, if required. These access modifiers determine thescope of visibility of the class and its methods and attributes.You also can add documentation information to a class. Notes and constraintscan be added to a list of attributes. Notes contain additional information forreference while developing the system, whereas constraints are the businessrules that the class must follow, and are text included in curly brace brackets.During the early phase of the system design conception, classes called Analysisclasses are created. Analysis classes are also called stereotypes. In the UMLcontext, stereotypes are UML models that that represent an existing UMLelement, while showing additional characteristics that are common across theclasses to be used for that application. Only one stereotype can be created forany UML element in the same system.Analysis classes are of the following types as per their behavior, as shown in thefollowing table:Class BehaviorBoundary In an ideal multi tier system, the user interacts only with the boundary classes. For example, JSPs in a typical MVC architecture form the boundary classes.Control These classes typically dont contain any business functionality. However, their main task is to transfer control to the appropriate business logic class, depending on a few inputs received from the 21
  22. 22. boundary classes. Entity These classes are those that contain the business functionality. Any interactions with back-end systems are generally done through these classes. • Interface: An interface is a variation of a class. As we saw from the previous point, a class provides an encapsulated implementation of certain business functionality of a system. An interface on the other hand provides only a definition of business functionality of a system. A separate class implements the actual business functionality. So, why would a class not suffice? You can define an abstract class that declares business functionality as abstract methods. A child class can provide the actual implementation of the business functionality. The problem with such an approach is that your design elements get tied together in a hierarchy of classes. So, even though you may not have intended to connect your design elements representing drastically different business entities, that is what might result. Hence, the use of the interface design construct in class diagrams. Different classes belonging to different and discrete hierarchies can maintain their distinct hierarchies and still realize the functionality defined in the methods of the interface. An interface shares the same features as a class; in other words, it contains attributes and methods. The only difference is that that the methods are only declared in the interface and will be implemented by the class implementing the interface. In addition to the above, there is one more element used in class diagrams: • Package: A package provides the ability to group together classes and/or interfaces that are either similar in nature or related. Grouping these design elements in a package element provides for better readability of class diagrams, especially complex class diagrams. Figure 4.1.2—a package From Figure 4.1.2, you can see a package is represented as a tabbed folder. A package can also have relationships with other packages similar to relationships between classes and interfaces.Relationships Between ClassesIn a class diagram, obviously you cant have classes just floating around; you need tosee the relationship between them. The following table shows the kinds of relationshipsbetween classes, their notation, and what they mean. 22
  23. 23. Sr. No. Relation Symbol Description1 Association When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:1 a. Multiplicity An example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).1 b. Directed Association between Association classes is bi-directional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container- contained relationship.1 c. Reflexive No separate symbol. However, An example of this kind Association the relation will point back at the of relation is when a same class. class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant.2 Aggregation When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is also called a "has a" relationship.2 a. Composition Composition is a variation of the aggregation 23
  24. 24. relationship. Composition connotes that a strong life cycle is associated between the classes.3 Inheritance/General Also called an "is a" ization relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.4 Realization In a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.A Few TermsHere are a few terms that we will be using to annotate our class diagrams. You shouldbe familiar with them: 1. Responsibility of a class: It is the statement defining what the class is expected to provide. 2. Stereotypes: It is an extension of the existing UML elements; it allows you to define new elements modeled on the existing UML elements. Only one stereotype per element in a system is allowed. 3. Vocabulary: The scope of a system is defined as its vocabulary. 4. Analysis class: It is a kind of a stereotype. 5. Boundary class: This is the first type of an analysis class. In a system consisting of a boundary class, the users interact with the system through the boundary classes. 24
  25. 25. 6. Control class: This is the second type of an analysis class. A control class typically does not perform any business functions, but only redirects to the appropriate business function class depending on the function requested by the boundary class or the user. 7. Entity class: This is the third type of an analysis class. An entity class consists of all the business logic and interactions with databases.Creating a Class DiagramClass diagrams can be modeled by using any UML tool that supports class diagrams.We will be using the Poseidon Community Edition tool to draw the class diagram. Youcan use any tool that you are comfortable with. Figure 4.1.3—a screen shot of the Poseidon toolThe screen shot of the Poseidon tool in Figure 4.1.3 shows the different options to modelclass diagrams and establish relationships among the packages, classes, and interfaces.Some additional features that you can check in your modeling tool are: • Support for forward and reverse engineering for class diagrams. A few sophisticated modeling tools also integrate with standard IDEs with support for round-trip engineering. • Documentation and report generation features 25
  26. 26. Dos and DontsClasses in a class diagram should be descriptive and must be named after businessentities. Using business entities as names ensures greater readability of class diagrams.Relationships between classes may not be apparent in the first iteration. Revise andrefine your class diagrams to determine possible relationships during each iteration.Designing is an incremental process and class diagrams are updated as the system getsbuilt. Hence, do not try to capture and freeze the class diagrams of a system in the firstpass.SummaryClass diagrams are the basic building block used to define the design of a system.Today, we learned about the elements of a class diagram—classes, interfaces, andpackages—and the different types of relationships among these elements such asassociation, aggregation, composition, generalization, and realization.In the next part in this article, we will take up a practical example, the CoursewareManagement system, and create the class diagrams for the system. UML DIAGRAM PART IIIntroductionIn the last article of this series, we saw what class diagrams were, and how to createclass diagrams. In todays article, we will see a practical example building on ourCourseware Management system case study.Case study—Courseware Management SystemThe class diagram of our Courseware Management System case study can be built aftera careful analysis of the requirements. In the previous article, we identified the primaryactors and use cases in the use case model of the case study. Because we did much ofthe groundwork of our analysis while building the use case model, we will use thoseanalysis steps as the basis for identifying the classes and interfaces of this system.Let us recap our analysis that we had performed when we designed the use case model.The following terms and entities specific to the system were identified from the problemstatement: • Courses and Topics that make up a course • Tutors who teach courses • Course administrators who mange the assignment of the courses to tutors • Calendar or Course Schedule is generated as a result of the • Students who refer to the Course schedule or Calendar to decide which courses for which they wish to sign upThe potential actors of the system were: 26
  27. 27. • Tutors • Course administrators • StudentsAnd the use cases of the system were: • View courses • Manage topics for a course • Manage course information • View course calendar • View tutors • Manage tutor information • Assign courses to tutorsIdentifying classes of the Courseware Management SystemAs we did in use case modeling, we will identify the classes and interfaces using anincremental approach. 1. Identify the "active" entities in the system The basic rule that we learned until now for identifying classes and interfaces is that classes and interfaces reflect important entities of the business domain of the system being modeled. We will apply this rule to determine classes and interfaces of the case study system. At first glance, the actors identified in the use case appear to be prime candidates for being listed as potential classes. Even though we had excluded Students and Tutors from our final list of actors, we will still include them in our list as potential classes. So, our first list of classes in the system appears to be: o Course administrators o Tutors o Students 2. Identify business domain ("passive") entities in the system But these are the "active" entities of the system. We had also identified "passive" elements in the system as well in the analysis for our use case model. These entities reflect the business domain and hence are potential classes for our system. o Courses o Topics that make up a course o Course calendar generated 27
  28. 28. Entities that reflect the business terms are also called business domain classes or just "domain classes." Some of the business domain classes hold transient data and some hold persistent data for the application. Normally, such business domain classes map to either one or many database tables. For example, in our case study, the Course class can be modeled as a database table cms_course. The data in this table for a particular course will be represented by an instance of the Course class and made available to the rest of the application. Our two-step process has definitely yielded promising results! We have covered all the relevant items in our analysis. So, let us list the list of classes and interfaces that we have identified in the Courseware Management System. o CourseAdministrator o Tutor o Student o Course o Topic o CourseCalendar3. Categorize and map the use cases and any relevant business functionality to either the passive or active entities. These will become the business methods of the classes in the system. Classes encapsulate functionality. The classes that we have identified for the Courseware Management System also provide business functionality related to the application. The functionality encapsulated by these classes is distinct in nature and differs from each class. Recall from our use case model, that, along with actors, we had identified a set of use cases that the actors interacted with. Let us try to associate them with our classes. Because our primary actor is the course administrator and the use cases were related to this actor, we can directly map the use cases to the CourseAdministrator class as methods. ClassName Methods CourseAdministrator viewCourses() manageCourse() manageTopic() viewCourseCalendar() viewTutors() manageTutorInformation() assignTutorToCourse() 28
  29. 29. In addition to this, we also can determine some implicit functionality of classes thatreflect business entities. For example, what functionality should the Course classprovide? Intuitively, we would define the Course class to provide functionality to viewall courses in the system, ability to create new courses or modify information of existingcourses, view the details of a particular course, or even remove a course from the system.We expect the Course class to provide such business functionality because the Courseclass reflects a business entity in the system. Hence, these become the methods exposedby the Course class. So, we can now refine the class diagram and add methods to each ofthese classes.To cut a long story short, each of the classes that reflect business entities will providesimilar implicit business functionality. Let us list all such "implicit" functionality for each ofthese classes. ClassName Methods Course viewAllCourses() viewCourseInformation() createCourse() modifyCourse() removeCourse() Topic viewAllTopics() viewTopicInformation() createTopic() modifyTopic() removeTopic() Tutor viewTutorInformation() createTutor() modifyTutor() removeTutor() CourseCalendar viewCourseCalendar() Student viewAllStudents() viewStudentInformation()Refine and revise the list of classes and interfacesRevisit the class diagram and revise it by identifying shared features and/or commonfunctionality between classes or interfaces. These will translate into reusable pieces ofcode for your system. To some extent, we can say that CourseAdministrator, Tutor, andStudent are essentially users of the system. Hence, we can define a shared parent classnamed User and define basic functionality like for example, authentication, in the Userclass that can be inherited by the CourseAdministrator, Tutor, and Student classes. It isleft to the design expertise to identify reusable classes/functionality.This completes our analysis of the problem statement to define the classes for theCourseware Management System. 29
  30. 30. Identifying relationships between the classes of the Courseware ManagementSystemThe next step after defining the classes of the Courseware Management System is todefine the relationships and dependencies between these classes and interfaces. Todefine the relationships between the classes, we need to analyze the interconnectionsbetween the classes—whether implicit or explicit. Relationship analysis can be brokenup into three steps: 1. Identify relationships between "active" entities Active entities normally share generalization relationships ("is-a"). Essentially, the common attributes and functionality between classes are defined in a common parent class. All the related child classes inherit functionality from the parent class. Apart from generalization, a few active entities can also be interconnected by a realization relationship. Recall that elements in a realization relationship implement declared functionality as a "contract." For example, a set of classes may implement functionality declared as methods in an interface, and this can be modeled as a realization relationship between the interface and the classes implementing the interface. In our case study, we do not find an example of inheritance relationship between the active entities such as Student, Tutor, and CourseAdministrator or any realization relationships. 2. Identify relationships between "passive" business entities Passive business entities frequently share plain association or aggregation relationships ("has-a"). This is especially true because these business entities are non-transactional in nature and reflect data more than behavior. It is by far quite intuitive to identify aggregation as well as its variations—composition relationships for passive business entities. Some of the classes in our case study do exhibit aggregation relationships. Because a set of topics makes up a course, we can define an aggregation relationship between the Course and Topic classes. Moreover, we can define this as a directed aggregation, meaning that you can check for the topics of a course but not vice versa. Similarly, we can define a plain association relationship between the Course and Tutor classes and Course and Student classes.Identify relationships between "active" and "passive" entitiesRelationships between active and passive entities can easily be represented usingdirected association. The directed association, a variation of the "vanilla" associationrelationship, provides easy identification of which is the container class and which is thecontained class. The CourseAdministrator class can be modeled to have a directedassociation with the Course class. This association can be named as "manages"because the course administrator manages courses as a business activity. In addition tothis, because the course administrator also manages the tutor information and topicinformation, we can model a directed relationship named as "manages" between theCourseAdministrator and the Course and Topic classes, respectively. We can enhancethe readability of the association between CourseAdministrator and the Course, Tutor,and Topic classes by defining the multiplicity for the association—one to many, one toone, many to many, and so forth. 30
  31. 31. Class diagram Figure 4.2.1 shows the class diagram for the Courseware Management SystemWe have completed identifying the classes for the Courseware Management System andestablished the relationships among the classes. Take a look at the class diagram inFigure 4.2.1. The class diagram of the Courseware Management System includes all theclasses and their relationships that we identified during our analysis of the problemstatement.Model View Controller DesignThe class diagram that we designed for the Courseware Management System defined thebasic classes necessary for representing the basic structure of the system. But this is byno means a complete design if the architecture of your system is to be based on theModel View Controller (MVC) architecture. Because an MVC model defines clearseparation of classes among the three layers—business, presentation, and flow control—you need to define additional classes and revise your design to include them. In case yourUML tool does not support explicit partitioning of classes, you can mark classes in each ofthe layers using stereotypes such as <<entity>>, <<boundary>>, <<control>>, and soforth.For example, in our case study application, we can revise the class diagram to define anew CMSController class that manages the flow of the application. The model layerprimarily consists of classes relevant to the business domain. Next, the classes that wehad defined can be categorized as transactional and persistent classes. TheCourseAdministrator class performs most of the activities in the system. Hence, this classcan be designated as a transaction class of the model layer. Similarly, the Course, Topic,Tutor, CourseCalendar, and Student classes represent persistent business data. Hence,these can be categorized as persistent classes of the model layer. Finally, you can definea set of classes that represent the presentation layer; in other words, the user interface ofthe system. 31
  32. 32. Forward Engineering from Class DiagramsForward engineering is the process of generating source code (in a specific language)from a class diagram model. The extent to which a UML class diagram can be used togenerate source code depends upon the limitations of the source code language.Because UML is pictorial, and can depict a lot of details, these details could be lost in thecode. Hence, before creating a complete class model, it is a good idea to be aware ofthe language that is going to be used, to limit the class model accordingly. Typically, theassociation relationships between classes are generated as member variables betweenthe related classes in the source code. Generalization relationships are generated asinheritance relationships in the source code. Figure 4.2.2 shows forward engineering a class diagramThe above screenshot shows the source code file generated for the CourseAdministratorJava source code file as a result of forward engineering the class diagram of theCourseware Management System case study. You need to check how forwardengineering works in the tool that you use.Reverse Engineering of Class DiagramsObtaining a class model from existing source code is called reverse engineering. This isgenerally done when it is required to understand the architecture of an existing system,either for re-engineering, or for maintenance. Reverse engineering is of great useespecially when trying to figure out the static structure and organization of a complexsystem. Typically, classes defined as member variables in the source code are modeledas association relationships between the classes. Inheritance relationships in the sourcecode are generated as generalization relationships between the classes. 32
  33. 33. Figure 4.2.3 shows reverse engineering a sample source code fileThe above screenshot shows a class diagram generated as a result of reverseengineering a sample source code file. You need to check how reverse engineeringworks in the tool that you use.SummaryIn the last article, we saw how class diagrams are the basic building blocks that definethe design of a system. We learned about the elements of a class diagram—classes,interfaces, and packages—and the different types of relationships among theseelements, such as association, aggregation, composition, generalization, and realization.Today, we defined a few steps to identify classes and interfaces of a system from aproblem statement for designing the class diagram for the Courseware ManagementSystem case study.Object Diagrams in UMLIntroductionIn the last article, you saw how your application could be represented in a class diagram.A class diagram is a static representation of your system. It shows the types of classes,and how these classes are linked to each other. In this edition of our series we introducethe object diagram. 33
  34. 34. BasicsAlthough we design and define classes, in a live application classes are not directlyused, 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 anypoint of time (called objects) is called an "Object diagram." It looks very similar to aclass diagram, and uses the similar notations to denote relationships.If an object diagram and a class diagram look so similar, what is an object diagramactually used for? Well, if you looked at a class diagram, you would not get the picture ofhow these classes interact with each other at runtime, and in the actual system, how theobjects created at runtime are related to the classes. An object diagram shows thisrelation between the instantiated classes and the defined class, and the relation betweenthese objects, in the logical view of the system. These are very useful to explain smallerportions of your system, when your system class diagram is very complex, and alsosometimes recursive.Let us now see what the components of an object diagram are. After this, we will build anobject diagram for our case study—Courseware Management system.Elements of an Object DiagramBecause an object diagram shows how specific instances of a class are linked to eachother at runtime, at any moment in time it consists of the same elements as a classdiagram; in other words, it contains classes and links showing the relationships.However, there is one minor difference. The class diagram shows a class with attributesand methods declared. However, in an object diagram, these attributes and methodparameters are allocated values.As an example, in the last article, a class diagram for a multiplicity relation betweencollege and students was shown, as you cam see in Figure 5.1: Figure 5.1—an example College-Student class diagramThis class diagram shows that many students can study in a single college. Now, if wewere to add attributes to the classes "College" and "Student," we would have a diagramas shown in Figure 5.2: Figure 5.2—the class diagram with attributes 34
  35. 35. Now, when an application with the class diagram as shown above is run, instances ofCollege and Student class will be created, with values of the attributes initialized. Theobject diagram for such a scenario will be represented as shown in Figure 5.3: Figure 5.3—the object diagram for the College-Student class diagramAs can be seen from Figure 5.3, the object diagram shows how objects are instantiatedin the running system represented by the College-Student class diagram. The classdiagram shows that a single college has many students, and defines the variables. Theobject diagram for the same system shows instantiated classes of Student (Student #1and Student #2) enrolled in College (Graduate School of Business).The object diagram shows the name of the instantiated object, separated from the classname by a ":", and underlined, to show an instantiation.Eg: Graduate School of Business: CollegeIn the diagram, values are assigned to variables and represented using the notationvariable name=variable value.This example was the representation of the relation of only two classes with each other.However, in a real application system, there will be multiple classes. An object diagramthen shows the relation between the instantiations of these classes. We shall see this inour case study.A class that defines the flow of the system is called as an active class. This classinstance in the object diagram is represented by thick border. In an MVC applicationarchitecture, the controller servlet is the action class, and is denoted by a thicker border.Also, multiple instances of the same class, as in a factory pattern, if the attributes of theindividual objects are not important, or are not different, these can be represented by asingle symbol of overlapping rectangles (see Figure 5.4): Figure 5.4—the object diagram for a Factory class 35
  36. 36. A class that performs more than one role, and is self-linked, is represented by a curvestarting and ending on itself, as illustrated in Figure 5.5: Figure 5.5—the object diagram for a self-linked classCreating an Object Diagram in PoseidonIn Poseidon, you will find the option to create object diagrams clubbed with the option tocreate deployment and component diagrams. Presently, Poseidon does not supportdisplay of attributes and methods in the object diagram; in other words, you can as ofnow only define an object of class, its type, and the linked objects. Hence, for our casestudy, we will use Microsoft Word to create an object diagram.The steps for creating an object diagram in Poseidon are as follows: 1. Open your Poseidon project file (the .zargo file) in which you created your class diagram earlier. 2. Make sure you are viewing your class diagram in the "Package centric," "Diagram centric," or "Inheritance centric" modes to view the deployment diagram. See Figure 5.6.the creation of an object diagram in Poseidon(objdiagram1) • Click on Create diagram -> Deployment/Object/Component diagram (or Ctrl+D) in the menu bar above. • Click on the object icon (shown in the black circle) in the icon menu bar on the top, to create an object. See Figure 5.7. • Fill in the Name of the Object instantiated, in the properties bar below. Select the class of which this object is an instance, in the area titled "Type." • After creating all the objects, click on the icon for "link" (shown in the red circle in Figure 5.7) to link the objects. Give the name of the link. • In case of our Case study, if we show an object diagram for the Course Administrator managing the Courses scenario, we get a diagram as shown in Figure 5.7.objectdiagram2—the object diagram in Poseidon for the case study Coursewaremanagement systemDos and DontsDos 1. Use the object diagram as a means of debugging the functionality of your system. 36
  37. 37. 2. Object diagrams can also be used to check whether the system has been designed as per the requirements, and behaves how the business functionality needs the system to respond. 3. Show associations of any kind between objects as linkages (for example, a single segment joining two objects, without arrows), and not as a dependency or any other specific type of association. An object diagram only shows the linkages, but not the type of association.Donts 1. Avoid representing all the objects of your system in an object diagram. Because an object diagram represents the state of objects, it can become quite complex if you try to represent all the objects. Hence, it is always better to represent the state of objects in certain important/critical flows in your application using an object diagram. This will keep your object diagram readable, yet useful enough to capture the state of objects that are important. 2. Because object diagrams represent the state of objects, forward engineering of object diagrams does not make sense.Case Study: Courseware Management SystemNow, we shall create an object diagram for the courseware system. To do this, we willfirst build up on our class diagram, and include the possible attributes and define theparameters of to the classes defined earlier.We will follow the following convention for the variable names:Names starting with "s_" are of the String data typeNames starting with "i_" are of the int data typeNames starting with "v_" are of the Vector data typeThe following table outlines the attributes, methods, and their return types for each of theclasses:Class Name Attributes MethodsCourseAdministrator s_adminId Vector viewCourses() v_courses Vector manageCourse(s_courseId) s_courseId Vector manageTopic(s_topicId) v_tutors Vector viewCourseCalendar(s_courseId) v_tutorInfo Vector viewTutors() s_tutorId Vector manageTutorInformation(s_tutorId) v_topics Boolean assignCourseToTutor(s_courseId, s_tutorId) s_topicId 37

×