Figure 1. UML 2.x component diagram.
Figure 2. UML 1.x component diagram.
Diagrams such asFigure 1are often referred to as “wiring diagrams” because they show how the various software components are “wired together” to build your overall application. The lines between components are often referred to as connectors, the implication being that some sort of messaging will occur across the connectors.
I usually draw component diagrams on whiteboards although for both of the examples I’ve used a drawing tool to depict the notation accurately. You can use component diagrams for both logical and physical modeling although I prefer to use them for physical modeling of the software architecture of a system.Figure 1shows the large-scale domain components for the system we’re building, including two user interface components which map to two different applications which we’re building as part of the overall system. This diagram includes both business and technical architecture aspects – the components with theinfrastructureanddatabasestereotypes are clearly technical in nature – and that’s perfectly fine. The important thing is that we’re considering both business and technical aspects in our architecture, not just technical issues, and for whatever reason we’ve chosen to create a single diagram which includes both views.
Interfaces and Ports
Components may both provide and require interfaces. An interface is the definition of a collection of one or more methods, and zero or more attributes, ideally one that defines a cohesive set of behaviors. A provided interface is modeled using the lollipop notation and a required interface is modeled using the socket notation. A port is a feature of a classifier that specifies a distinct interaction point between the classifier and its environment. Ports are depicted as small squares on the sides of classifiers.
For example,Figure 3shows a detailed component diagram which contains three components. There are several interesting features to note about this diagram:
- Ports can be named, such as theSecurityandDataports on theStudentcomponent.
- Ports can support unidirectional communication or bi-directional communication. TheStudentcomponent implements three ports, two unidirectional ports and one bi-directional ports. The left-most port is an input port, theSecurityport is an output port, and theDataport is a bi-directional port.
- TheStudentAdministrationandStudentScheduleinterfaces are application specific and may include overlapping method signatures. I’ve found this approach to be more understandable to the clients of the component as each application team is provided their own specific interface which isn’t encumbered with methods they don’t need.
- The diagram isn’t “wired” together yet – I haven’t connected theStudentcomponent to the two security components yet.
- You don’t need to use all of the provided interfaces of a component. My team has decided to use theX-Securitycomponent foraccess controland theMegaEncryptercomponent for encryption. Both of these fictional components are commercial off the shelf packages (COTS) which we’ve purchased. AlthoughX-Securityimplements both security interfaces required byStudentthe other component implements theEncryptioninterface much more efficiently so we’ve decided to use both security components.
Figure 3. Modeling interfaces and ports.
So how do you actually build a component? Although there are various strategies to do so, there are several basic principles that you can follow.Figure 4depicts a design for the Student component, depicting it as a UML frame. It’s also common to use “composite structure“, e.g. a rectangle with the component stereotype in the top-right corner, instead of a frame because a component really is a structure composed of smaller elements. Whether you call it a frame, a composite structure, or something else, the diagram is pretty much the same. Interesting points about this diagram are:
- I simplified the ports to either provide or require a single interface. This enables me to easily and explicitly model the relationships between the ports and the internals of the component.
- I’ve modeled relationships between ports and internal classes in three different ways: as a stereotyped delegates relationship, as a delegates relationship, and as a realizes relationship. A delegates relationship is a line with an open arrowhead on it and a realizes relationship is a dashed arrow with a closed arrowhead. Because the delegates notation is exactly the same notation that is used for unidirectional associations there is an opportunity for confusion – as a result I recommend indicating the stereotype on the relationship to make it clear what you mean. The realizes notation, for exampleAdministrationFacaderealizes the port containing theStudentAdministrationinterface, used to be my preferred approach because in my mind ports are logical modeling constructs that are realized by physical constructs such as classes. However, the delegates association has the advantage that it indicates the flow of communication and as a result seems to be easier to understand.
- TheDataandSecurityclasses use the same names as the corresponding ports.
- Classes such asAdministrationFacade,ScheduleFacade,StudentData,Data, andSecurityimplement the Façade design pattern (Gamma et. al. 1995). The basic idea is that they implement the public operations required by the interfaces, operations that typically just delegate messages to the appropriate classes. Together theAdministrationFacade,ScheduleFacade, andStudentDataclasses implement the public interface of theStudentcomponent.StudentData,Data, andSecuritywrap access to external components so that the internal classes are not directly coupled to other physical components.
- Expect to adapt incoming/outgoing interactions back and forth between data-oriented and object-oriented messages. An incoming message may be implemented as a web service which takes XML as a parameter and returns XML as the result. The internal objects within the component, on the other hand, need messages sent to them with either objects or data as parameters and return values. The implication is that you need to marshal the data and objects back and forth between each other, something addressed by theAdapterdesign pattern (Gamma et al., 1995).
- Another way to implement the public interface would have been to implement a single façade class calledStudentComponentwhich implements the required public interfaces and delegates appropriately.
- When designing theStudentDataclass the team realized that it needed to work with our existingXMLProcessorcomponent, therefore we added the connection to this component.
Figure 4. Designing a component.
Figure 3makes it obvious that building components is costly. Creating theStudentcomponent as shown inFigure 3doesn’t make much sense – I’ve added five new classes to support two domain classes, a clear case of overbuilding. This approach would make sense if there was twenty classes, and would make a lot of sense for fifty domain classes, because the additional five classes reduce the coupling within your system while at the same time implement a large-scale, reusable domain component. The point is that you should only take a component-based approach when the benefit of doing so outweighs the additional cost.
There are two fundamental strategies for developing a component model, either top down or bottom up. Given the choice I prefer the top-down approach because it provides a good mechanism for identifying the “software landscape” early in the project, something that is particularly important for teams comprised of several subteams because you want to work towards the same vision. Unfortunately a top-down approach suffers from the tendency to promote over-architecting, and hence over-building, of your system. For exampleFigure 1calls outSecurityandPersistencecomponents but you might not yet need anything even remotely that complicated. It would be a serious mistake to focus on building these two components instead of implementing actual business functionality that your stakeholders actually need.
A second way to develop component models is from the bottom up. I’ll do this when we have an existing collection of classes that have been developed and we decide to componentize our design. Componentizing is often done to rescue reusable functionality out of an existing application or to split an application up so it can be easily dispersed between subteams. When I’m componentizing an existing object design I’ll often iterate through the following steps:
- Keep components cohesive. A component should implement a single, related set of functionality. This may be the user interface logic for a single user application, business classes comprising a large-scale domain concept, or technical classes representing a common infrastructure concept.
- Assign user interface classes to application components. User interface classes, those that implement screens, pages, or reports, as well as those that implement “glue logic” such as identifying which screen/page/”� to display should be placed in components with theapplicationstereotype. In Java these types of classes would include Java Server Pages (JSPs), servlets, and screen classes implemented via user interface class libraries such as Swing.
- Assign technical classes to infrastructure components. Technical classes, such as those that implement system-level services such as security, persistence, or middleware should be assigned to components which have theinfrastructurestereotype.
- Define class contracts. A class contract is any method that directly responds to a message sent from other objects. For example, the contracts of theSeminarclass likely include operations such asenrollStudent()anddropStudent(). For the purpose of identifying components, you can ignore all the operations that aren’t class contracts because they don’t contribute to communication between objects distributed in different components.
- Assign hierarchies to the same component. 99.9% of the time I find that it makes sense to assign all of the classes of a hierarchy, either an inheritance hierarchy or a composition hierarchy, to the same component.
- Identify domain components. A domain component is a set of classes that collaborate among themselves to support a cohesive set of contracts. The basic idea is that classes, and even other domain components, are able to send messages to domain components either to request information or to request an action be performed. On the outside, domain components appear simple, actually they appear like any other type of object but, on the inside, they are often quite complex because they encapsulate the behavior of several classes. A key goal is you want to organize your design into several components in such a way as to reduce the amount of information flowing between them. Any information passed between components, either in the form of messages or the objects that are returned as the result of a message send, represents potential traffic on your network (if the components are deployed to different nodes). Because you want to minimize network traffic to reduce the response time of your application, you want to design your domain components in such a way that most of the information flow occurs within the components and not between them.
- Identify the “collaboration type” of business classes. To determine which domain component a business class belongs to you need to analyze the collaborations it is involved with to determine its distribution type. A server class is one that receives messages, but doesn’t send them. A client class is one that sends messages, but doesn’t receive them. A client/server class is one that both sends and receives messages. Once you have identified the distribution type of each class, you are in a position to start identifying potential domain components.
- Server classes belong in their own component.Pure server classes belong in a domain component and often form their own domain components because they are the “last stop” for message flow within an application.
- Merge a component into its only client.If you have a domain component that is a server to only one other domain component, you may decide to combine the two components.
- Pure client classes don’t belong in domain components.Client classes don’t belong in a domain component because theyonly generate messages, they don’t receive them, whereas the purpose of a domain component is to respond to messages. Therefore, client classes have nothing to add to the functionality offered by a domain component and very likely belong in an application component instead.
- Highly coupled classes belong in the same component.When two classes collaborate frequently, this is an indication they should be in the same domain component to reduce the network traffic between the two classes. This is especially true when that interaction involves large objects, either passed as parameters or received as return values. By including them in the same domain component you reduce the potential network traffic between them. The basic idea is that highly coupled classes belong together.
- Minimize the size of the message flow between components.Client/serverclasses belong in a domain component, but there may be a choice as to which domain component they belong to. This is where you need to consider issues such as the information flow going into and out of the class. Communication within a component will often be simple message sends between objects in memory, communication between components may require an expensive marshalling effort in which a message and its parameters are converted to data, transmitted, and then converted back into a message again.
- Define component contracts. Each component will offer services to its clients, each such service is a component contract.
Table 1summarizes several design principles presented in Agile Software Development (Martin, Newkirk, Koss 2003) for improving the quality of packages or components. I present them here because I find them of greatest value when it comes to component modeling.
Table 1. Component design principles.
|Acyclic Dependencies||Allow no cycles in the dependencies graph between components. For example disallow A B C A because it includes a cycle.|
|Common Closure||The classes of a component should be closed together against the same kinds of changes. A change that affects a class within a component should not affect classes outside that component. In other words your components should be cohesive in that sweeping changes across several components are not required.|
|Common Reuse||The classes in a component are reused together. If you reuse one class in a component you reuse them all. This is another principle addressing cohesion.|
|Dependency Inversion||Abstractions should not depend on details, instead details should depend on abstractions.|
|Open-Closed||Software elements should be open for extension but closed for modification.|
|Release-Reuse Equivalency||The granule of reuse is the granule of release. In other words you should not reuse only part of a released software element.|
|Stable Abstractions||A component should be as abstract as it is stable. A component should be sufficiently abstract so that it can be extended without affecting its stability.|
|Stable Dependencies||Depend on the direction of stability – If component A depends on component B, then B should be more stable (e.g. less likely to change) than A.|
My most successful use of component models was with a team where we drew a diagram similar to, albeit a much larger one with over twenty components, on a whiteboard. This whiteboard was situated in the team work area where everyone could see the board. We developed the diagram early in theinitiativeand updated it as required throughout the project. We kept it on the board because it provided a high-level map of the architecture of our software, a map that we used from time to time as we worked and more importantly engendered many interesting conversations regarding the overall system design.
There are several advantages to components that promote agility. First, components are reusable building blocks from which you can build software, increasing your productivity as a developer. Second, components can improve your testing productivity because they can be treated as elements which you can black-box unit and integration test. Testing is discussed in detail inAgile Testing and Quality Strategies.
This artifact description is excerpted from Chapter 10 ofThe Object Primer 3rd Edition: Agile Model Driven Development with UML 2.
The notation used in these diagrams, particularly the hand drawn ones, may not conform perfectly to the current version of the UML for one or more of reasons:
- The notation may have evolved from when I originally developed the diagrams. The UML evolves over time, and I may not have kept the diagrams up to date.
- I may have gotten it wrong in the first place. Although these diagrams were thoroughly reviewed for the book, and have been reviewed by thousands of people online since then, an error may have gotten past of us. We’re only human.
- I may have chosen to apply the notation in “non-standard” ways. An agile modeler is more interested in created models which communicate effectively than in conforming to notation rules set by a committee.
- It likely doesn’t matter anyway, because themodeling tool(s)that you’re using likely won’t fully support the current version of the UML notation perfectly anyway. Bottom line is that you’re going to be constrained by your tools anyway.
If you’re really concerned about the nuances of “official” UML notation then read the current version of theUML specification.
An Agile Introduction – The Agile Modeling (AM) Method:? ›
Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on an initiative in an effective and streamlined manner.What is the introduction of Agile methodology? ›
Agile methodologies are designed to be adaptive and responsive to changing requirements and priorities. Agile emphasizes collaboration between teams, customers, and stakeholders and encourages open communication and transparency throughout the project lifecycle.What is the agile model approach? ›
Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles, that can be applied on an (agile) software development project.What are the 4 core principles of Agile methodology? ›
4 values of Agile
Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a project plan.
- Communication. The value of communication refers to the importance of having a shared understanding of the problems to be solved (requirements) and the design that can enable an optimal solution. ...
- Simplicity. ...
- Feedback. ...
- Courage. ...
The Agile methodology is a project management approach that involves breaking the project into phases and emphasizes continuous collaboration and improvement. Teams follow a cycle of planning, executing, and evaluating.What is Agile in simple terms? ›
At its simplest, Agile simply means continuous incremental improvement through small and frequent releases. The term Agile is most commonly associated with software development as a project management methodology.What is an example of an agile model? ›
Examples of Agile Methodology. The most popular and common examples are Scrum, eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal, and Lean Software Development (LSD).What does the Agile model focus on? ›
Agile methods focus on the ability of a team to be flexible, encouraging team members to identify uncertainties in their projects and adapt to challenges. The Agile methodology is most associated with software development projects. However, you can apply it to any industry, project, or position.What is the primary goal in agile modeling? ›
Simplicity: The goal of Agile modelling is to make concepts and processes simple to understand. It is meant to make software development easier and to set up clear guidelines for developing models.
What are the 6 phases of Agile model? ›
The Agile software development life cycle is the structured series of stages that a product goes through as it moves from beginning to end. It contains six phases: concept, inception, iteration, release, maintenance, and retirement.What are the 3 C's agile? ›
The three Cs stand for Card, Conversation and Confirmation and in this article, I'm going to discuss each of the elements, explaining why, and how to ensure you're doing it right. I'll also scatter in a few tips from my experiences with agile teams.What are the 4 phases of agile project management methodology? ›
The five different phases of the Agile Project Management framework include the envision phase, the speculate phase, the explore phase, the adapt phase, and the close phase.Why is Agile model the best? ›
Agile development is important because it helps to ensure that development teams complete projects on time and within budget. It also helps to improve communication between the development team and the product owner. Additionally, Agile development methodology can help reduce the risks associated with complex projects.What are the 3 pillars of Scrum? ›
If you carefully scrutinize scrum, you will find again and again the three pillars of empirical process control: transparency, inspection, and adaptation.
The primary difference between Agile and Scrum is that Agile is a project management philosophy that employs a fundamental set of values or principles, whereas Scrum is a precise Agile methodology utilized to facilitate a project.What does scrum stand for? ›
The term scrum is borrowed from rugby, meaning a formation of players. The paper's authors employed this sports' term, scrum, in order to emphasize teamwork, since close, daily collaboration of team members is a hallmark trait of the project management framework.What is difference between Agile and Agile methodology? ›
Agile is neither a methodology or a framework, meaning methodology or a process is much more complete and will specify how work should be done whereas a framework, on the other hand, is purposely incomplete ( like SCRUM, XP, Crystal). So agile is a set of principles and values.What is Agile best answer? ›
Agile is a popular set of methods and practices that majorly focuses on interactive development. Thanks to self-organizing collaborations between cross-functional teams, the requirements from their customers and potential solutions are obtained.What is an example of agile at work? ›
Agile working is not just about allowing employees to work from home and decide their own working hours. Another example of agile working might be workspaces designed to suit the different kinds of work taking place. This is an environment that helps people to be at their best and most productive.
What projects use Agile model? ›
Agile project management methodology is commonly used for software development projects. It has greater adaptability to frequently changing scope. As a consequence, agile project management uses iterative or phased planning and continuous integration throughout the life of the project.What is the most important Agile objective? ›
An Agile focus should be on improving the product and advancing consistently. Simplicity — the art of maximizing the amount of work not done — is essential. The goal is to get just enough done to complete the requested project.What are the 5 phases of a scrum? ›
Scrum is an Agile project management framework that enables teams to work together in an efficient, organized way. It is divided into five distinct phases - initiation, planning and estimates, implementation, review and retrospective, and release phase.What is principle 7 in SAFe agile? ›
Principle #7 – Apply cadence, synchronize with cross-domain planning. Solution development is an inherently uncertain process. If it weren't, the solutions would already exist, and there would be no room for the next generation of innovations.What is principle 7 Agile Manifesto? ›
Nothing demonstrates real progress better than delivering working software to the customer frequently. That's the focus of the seventh principle of Agile: Working software is the primary measure of progress.What is 101 of the agile? ›
Agile 101 begins with understanding that agile can be applied to anything. You can use agile practices to improve your personal task management, optimize workplace efficiency, or align software teams around product development.What is the most popular Agile model? ›
Scrum is the most popular agile development methodology. Teams work in time-boxed sprints of two to four weeks and each person has a clearly delineated role, such as scrum master or product owner.What are three 3 advantages of Agile method? ›
Agile produces important metrics like lead time, cycle time, and throughput that helps measure the team's performance, identify bottlenecks and make data-driven decisions to correct them. The Agile framework is a powerful tool that helps managers, team members, and clients.What are 3 benefits of an Agile approach? ›
- Increased visibility.
- Increased adaptability (agility)
- Increased alignment.
- Increased product quality.
- Increased business value.
- Increased customer satisfaction.
- Decreased risk.
These 3 C's are Cards, Conversation, and Confirmation. These are essential components for writing a good User Story. The Card, Conversation, and Confirmation model was introduced by Ron Jefferies in 2001 for Extreme Programming (XP) and is suitable even today. So, let us examine these 3 C's for writing User Stories.
Who owns the sprint backlog? ›
Who Owns the Sprint Backlog? According to the scrum framework, the entire agile team — scrum master, product owner, and development team members — will share ownership of the sprint backlog. This is because all members of the team will bring unique knowledge and insights to the project at the beginning of each sprint.Are there 3 ceremonies in Scrum? ›
There are five scrum ceremonies, sprint planning, daily standup, sprint review, sprint retrospective and product backlog grooming.Why was Agile methodology introduced? ›
The Agile methodology originated in the software development industry as a new way to manage software development. Many software development projects were failing or taking much too long to complete, and industry leaders realized they needed to find a new, innovative approach.What is Agile methodology and why? ›
Agile development is important because it helps to ensure that development teams complete projects on time and within budget. It also helps to improve communication between the development team and the product owner. Additionally, Agile development methodology can help reduce the risks associated with complex projects.When was Agile methodology introduced? ›
Agile was formally launched in 2001, when 17 technologists drafted the Agile Manifesto. They wrote four major principles for agile project management, intended to guide teams on developing better software: Individuals and interactions over processes and tools.What is the main point of Agile? ›
The principles behind the Agile Manifesto.
The highest priority is to satisfy the customer through early and continuous delivery of valuable software. The project team welcomes changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
According to the Agile Manifesto, the more important values are individuals and interactions, working software, customer collaboration, and responding to change.How do you explain Agile methodology in an interview? ›
The Agile methodology doesn't tell you to stick to a set of prescribed steps or processes. It emphasizes adapting to the needs of your team, customer, and the changes in your environment and project requirements. The goal of Agile is to produce working results in a way that's repeatable and continuous.What is the first principle of agile? ›
Agile Principle 1
The idea is to get a working product in the hands of customers as soon as possible. Doing this successfully means product managers are able to quickly get a minimum viable product (MVP) out and into the world and use it to get feedback from real customers.
Scrum has three roles: product owner, scrum master, and the development team members.
How many agile principles are there? ›
The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development.What do the 4 values of agile mean? ›
The Agile Manifesto consists of four key values: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.What are the benefits of Agile? ›
- Increased visibility.
- Increased adaptability (agility)
- Increased alignment.
- Increased product quality.
- Increased business value.
- Increased customer satisfaction.
- Decreased risk.
The primary difference between Agile and Scrum is that Agile is a project management philosophy that employs a fundamental set of values or principles, whereas Scrum is a precise Agile methodology utilized to facilitate a project.